home *** CD-ROM | disk | FTP | other *** search
/ Aminet 25 / Aminet 25 (1998)(GTI - Schatztruhe)[!][Jun 1998].iso / Aminet / gfx / conv / mpegPPC.lha / doc / ARCHITECTURE next >
Text File  |  1998-04-17  |  7KB  |  171 lines
  1. This file contains a couple of (currently unstructured and incomplete) encoder
  2. implementation notes.
  3.  
  4. Basic Assumptions
  5.  
  6. - data structures
  7.  
  8. Primary data structures are:
  9.  
  10.  - picture data arrays, containing either source or reconstructed pels
  11.  
  12.  - mbinfo array, containing all macroblock level side information
  13.  
  14.  - blocks array, containing DCT coefficients
  15.  
  16. mbinfo and blocks together are completely equivalent to the VLC encoded
  17. picture_data() part of the MPEG stream, although in uncompressed and
  18. therefore rather voluminous internal format.
  19.  
  20. a) picture data arrays
  21.  
  22. Frames are represented internally as in the following declaration:
  23.  
  24. unsigned char *frame[3];
  25.  
  26. i.e., an array of three pointers to the picture data proper. frame[0]
  27. points to the luminance (Y) data, frame[1] to the first chrominance (Cb, U)
  28. component, frame[2] to the second chrominance component (Cr, V).
  29.  
  30. Width and height of the luminance data array is 16*mb_width and 16*mb_height,
  31. even if horizontal_size and vertical_size are not divisible by 16. The
  32. actual pels are top left aligned and padded to the right and bottom (by
  33. pixel replication) while being read into the encoder.
  34.  
  35. Width and height of the two chrominance arrays depends on the chroma_format.
  36. For 4:2:0 data, they are half size in both directions, for 4:2:2 data only
  37. width is half that of the luminance array, for 4:4:4 data, chrominance and
  38. luminance are of identical size.
  39.  
  40. The dimensions are stored in the following global variables:
  41.  
  42.              | horizontal   | vertical
  43. -------------+--------------+------------
  44. luminance    | width        | height
  45. chrominance  | chrom_width  | chrom_height
  46.  
  47. Picture data (array of pels) is always stored as frames, even when a
  48. field picture sequence is to be generated. The two fields are stored
  49. in interleaved from, that is alternating lines from both fields. In
  50. most cases, however, it's easier to view the two fields as being stored
  51. side to side of each other as an array of double width and half height.
  52. The following picture demonstrates this:
  53.  
  54.  <----- width --------->
  55.  T1 T1 T1 T1 T1 T1 T1 T1 <+
  56.  B1 B1 B1 B1 B1 B1 B1 B1  |
  57.  T2 T2 T2 T2 T2 T2 T2 T2  | height
  58.  B2 B2 B2 B2 B2 B2 B2 B2  |
  59.  T3 T3 T3 T3 T3 T3 T3 T3  |
  60.  B3 B3 B3 B3 B3 B3 B3 B3 <+
  61.  
  62.  <------------- 2*width (width2) --------------->
  63.  T1 T1 T1 T1 T1 T1 T1 T1  B1 B1 B1 B1 B1 B1 B1 B1 <+
  64.  T2 T2 T2 T2 T2 T2 T2 T2  B2 B2 B2 B2 B2 B2 B2 B2  | height/2 (height2)
  65.  T3 T3 T3 T3 T3 T3 T3 T3  B3 B3 B3 B3 B3 B3 B3 B3 <+
  66.  
  67.  Tn: top field pels
  68.  Bn: bottom field pels
  69.  
  70. These are of cause only two different two-dimensional interpretations of
  71. the same one-dimensional memory layout. Either the top or the bottom field
  72. can be the earlier field in time.
  73.  
  74. The following table shows the relation between width, height, width2 and
  75. height2 for frame and field pictures:
  76.  
  77.          | frame  | field
  78.  --------+--------+---------
  79.  width2  | width  | 2*width
  80.  height2 | height | height/2
  81.  
  82. Using the convenience variables width2 and height2, many loops are
  83. independent of frame / field picture coding.
  84.  
  85.  
  86. b) mbinfo array
  87.  
  88. This array contains the complete encoded picture (field or frame),
  89. except the DCT coefficients. This includes macroblock type, motion vectors,
  90. motion vector type, dct type, quantization parameter etc. The number
  91. of entries (size of the array) is identical to the number of macroblocks
  92. in the picture.
  93.  
  94. c) blocks
  95.  
  96. This array contains all DCT coefficients of the picture. It is declared as
  97.  
  98. EXTERN short (*blocks)[64];
  99.  
  100. i.e. a pointer to an array whose elements are blocks of 64 short integers
  101. each. The number of blocks is block_count times the number of macroblocks
  102. in the picture. block_count depends on the chroma format (6, 8 or 12 blocks
  103. per macroblock).
  104.  
  105. The actual content depends on the encoding stage. Either prediction error
  106. (or intra block data), DCT transformed data, quantized DCT coefficients or
  107. inverse transformed data is stored in blocks. This is done to keep
  108. memory requirements reasonable.
  109.  
  110.  
  111. Encoding procedure
  112.  
  113. The high-level structure of the bitstream is determined in putseq().
  114. This includes writing the appropriate headers and extensions and the
  115. decision which picture coding type to choose for each picture.
  116.  
  117. Encoding of a picture is divided into the following steps:
  118.  
  119. - motion estimation (motion_estimation())
  120. - calculate prediction (predict())
  121. - DCT type estimation (dct_type_estimation())
  122. - subtract prediction from picture and perform DCT (transform())
  123. - quantize DCT coefficients and generate VLC data (putpict())
  124. - inverse quantize DCT coefficients (iquant())
  125. - perform IDCT and add prediction (itransform())
  126.  
  127. Each of these steps is performed for the complete picture before
  128. proceding to the next one. The intention is to keep these
  129. steps as independent from each other as possible. They communicate
  130. only via the above mentioned basic data structures. This should simplify
  131. experimenting with different coding models.
  132.  
  133. Quantization and VLC generation could not be separated from each other,
  134. as quantization parameters and output buffer content usually form a
  135. closed loop on macroblock level.
  136.  
  137. - Motion Estimation
  138.  
  139. The procedures for motion estimation are in the file motion.c. The main
  140. function motion_estimation() loops through all macroblocks of the current
  141. picture calling frame_ME (for frame pictures) or field_ME (for field
  142. pictures) to calculate motion vectors for each macroblock.
  143.  
  144. Motion estimation is currently done separately. More efficient schemes
  145. like telescopic motion estimation, which span several pictures (e.g.
  146. two I/P pictures and all intervening B pictures), are not yet implemented.
  147.  
  148. Motion estimation splits into three steps:
  149.  
  150. - calculation of optimum motion vectors for each of the possible motion
  151.   compensation types (frame, field, 16x8, dual prime)
  152.  
  153. - selection of the best motion compensation type by calculating and comparing
  154.   a prediction error based cost function
  155.  
  156. - selection of either motion compensation or any other possible encoding
  157.   type (intra coding, No MC coding)
  158.  
  159. Motion vectors are estimated by integer pel full search in a search window
  160. of user defined size. This full search is based on the original source
  161. reference pictures. Subsequently the cost functions for the 9 motion vectors
  162. with an offset of -0.5, 0, and 0.5 relative to the best integer pel vectors
  163. are evaluated (using the reconstructed reference picture) and the vector with
  164. smallest cost function is used as estimation.
  165.  
  166. To speed up full search, the cost function calculation is aborted if the
  167. intermediate values exceed the cost function value of an earlier motion
  168. vector in the same full search. This is most efficient if vectors of
  169. potentially low cost are evaluated fist. Therefore full search is organized in
  170. an outward spiral.
  171.